Dialog boxes in a typical windowing software user interface are generally invoked, placed on the screen, used, and then dismissed. There are two types of dialogs: modal and modeless. A modal dialog requires the user to close the dialog before continuing to work in the application, whereas the modeless dialog allows the dialog to remain visible while the user continues to work in the application. In either case the general usage remains the same, even though the modeless dialog offers the flexibility of remaining present while the user continues to work. This style of dialog which floats on top or foreground of the rest of the application has several disadvantages.
One disadvantage to this style of floating dialog includes the fact that the dialog is typically placed near the center of the screen concealing the work area. Another disadvantage is that the placement of the dialog is arbitrary relative to where it was invoked from, forcing the user to move their mouse as well as their attention to a different region of the screen. Another disadvantage is that the dialog must be explicitly closed with an additional click after use. Another disadvantage is that the dialog does not stay in one place relative to the application frame when moved or resized and does not make optimal use of working space.
Parts of the problem described above have been addressed with the utilization of dockable dialogs and drop-down dialogs. However, neither of these solutions address the entire problem.
A dockable dialog is a modeless dialog which when docked, fixes itself to a designated area of the application's work area, such as an edge. This designated area of the application work area is called a docker. The docker may be a location in a window of the application environment. A dockable dialog may be removed from the docker and float in another location of the window. Dockable dialogs floating in a window of an application framework may be docked on a docker.
In a different solution, drop-down dialogs are used. The drop-down dialogs may come in the form of flyout (or drop-down) toolbars and menus, placed adjacent to their corresponding flyout button minimizing mouse and eye movement. Dropdown dialogs may be automatically dismissed when a user clicks on a part of the application's work area away from the flyout toolbar. The drop-down dialog may be torn-off from the flyout button and float in a window of the application environment.
Traditional dockable dialogs and drop-down dialogs do not communicate with each other. A traditional drop-down dialog cannot dock on a docker. Thus, users are limited to having either a drop-down dialog or a docking dialog. Using both types of dialogs simultaneously may take up limited window space in the application framework. As the simultaneously running dialogs do not communicate with each other, users may confuse a floating drop-down dialog with a floating dockable dialog. Furthermore, users may experience frustration when an attempt to dock a drop-down dialog fails.